是的。时髦有风险。

Node 能做的，Sinatra + Sequel（ORM）其实都行。我经常用这个渲染页面。

Ruby 下的 Sequel（ORM）0 BUG，实在是强。

https://dontusesystemruby.com/

也提到了安装方法

Raw SQL 遇到过错误 https://github.com/prisma/prisma/issues/21570

我以为这种 RawSQL 的 API 是软件的底层，应该先设计。结果一年多都没解决。

吹自己是次世代，我现在对 JavaScript 的东西保持怀疑。

次世代框架你也不能说它错，反正不是“现代”能用的框架。

放弃了

JRuby 对 需要本地编译的 C 拓展不友好。大多数游戏 lib 都是 C。 Truffleruby 虽然说支持 C 拓展，结果一样，跑不起来。

做一个前置的 Installer 不论是脚本，还是显式的安装器，帮用户处理

• 安装 依赖
• 安装 Ruby
• 添加到 PATH
• 安装或构建 Gems

只有这个比较简单、中规中矩。并且可靠，是被广泛测试过可靠的路径。

自己打包 Ruby 这条路，实际 Ruby 或者 Gem 的打包一直是动态的，需要长期跟踪，成本太高。不建议个人做。

homebrew 学习 Rails 实际上并不是很好。

以 我的环境为例 MacOS 13.6.6（Intel) 为例

1）brew install ruby 确实可以正确安装 ruby

他的位置在 /usr/local/opt/ruby/bin/ 都添加到 path。Ruby 自己的组件：ruby、gem、irb 都工作正常

2）当你 gem install rails，正常安装成功，如果你什么都不做，你根本找不到 rails，rails 无从执行。

因为它的位置在 /usr/local/lib/ruby/gems/3.3.0/bin/ ，你需要自己添加到 PATH。 这对新手并不友好。位置在 M1(ARM) 系列的位置可能还不同。这个 PATH 谁来告知？搜索引擎 maybe。。。

实际上，用户得非常留意安装信息里面，才能看到这句；或者说很熟悉 homebrew，再去用 brew info ruby 重新获取。

By default, binaries installed by gem will be placed into:
  /usr/local/lib/ruby/gems/3.3.0/bin

而且这个丑陋的 PATH 还依赖固定版本。

用户还得 会点 vim，maybe shell，知道当前终端是什么，初始化文件在哪儿，还得用 source。 而这一切默认你已经会了。新人不会被告知。 :(

ASDF 帮助解决了 python、ruby、nodejs ……

• 1) 需要需要构建，需要的前置依赖
• 2）用户的环境情况，配置的文档
• 3）初始化
• 4）这些语言各自的包管理 安装对应包，添加 PATH，动态切换 PATH 的问题。初始化一次，再也不用关心

同感。asdf 确实不错，只是对于开发还 ok。对于只想运行 ruby 的人来说，还是太繁琐。

我还在研究 portable ruby。理想情况：做出了比较完善的，也可以做到直接下载，添加到 path 就可以工作了。免去了本地编译的问题。

这是最近想把 ruby 带着走，产生的想法。

构建有一个过程，需要等待。编译完会自动安装 make install .... 结束就好了

emmm…… 是这样

1.Portable Ruby 可能更高级一点

比如你想把 Ruby+Rails+ 你的应用，带着走。用上面的可能合适。

但是没必要，因为你在学习 Rails 不要把自己放在这些奇怪的情境中。

2.如果你只想正常运行 ruby，开发 Rails，而且不想遇到 sudo 问题

我推荐 asdf，这也是我本人开发用的个 asdf 可以管理多个语言、数据库、任何版本相关的。

1）在这里 https://asdf-vm.com/ 安装 asdf

2）添加 ruby

https://github.com/asdf-vm/asdf-ruby

可以参考我之前的博客： https://mark24code.github.io/ruby/2021/12/24/Ruby%E7%8E%AF%E5%A2%83%E6%90%AD%E5%BB%BAasdf+ruby+gem+bundler+%E6%BA%90%E6%9B%BF%E6%8D%A2.html

不过可能有点过时。在安装依赖这部分。Ruby 3.3.1 依赖 openssl@3 这是重点。

# 安装前置依赖
# ruby-build 是安装工具
# openssl@3 readline libyaml gmp 是必要的依赖
# rust 是 YJIT 必要的依赖，不装就不会构建 YJIT 功能

brew install ruby-build openssl@3 readline libyaml gmp rust

补一篇《使用 Ruby-build 在 MacOS 上 编译 Portable Ruby》https://ruby-china.org/topics/43710

随便试试，可以用 Ruby build 安装到任意路径，可移除。

# step1: 安装前置依赖
# ruby-build 是安装工具
# openssl@3 readline libyaml gmp 是必要的依赖 
# rust 是 YJIT 必要的依赖

brew install ruby-build openssl@3 readline libyaml gmp rust

# step2: 编译安装
# $HOME/ruby 替换成你要安装的目录
# 搜索到 ruby 需要把 $HOME/ruby/bin 添加到到你的 PATH

ruby-build 3.3.1 $HOME/ruby

长期使用，推荐 asdf 安装，统一管理。ruby 插件的底层依然是 ruby-build

https://asdf-vm.com/

今天我在群里，提出了类似的问题。

Ruby 在 MacOS 上的安装，有点不友好。

不如 Python、Java 简单粗暴

《Ruby 基础教程（第 5 版）》 https://www.ituring.com.cn/book/1843

CRuby 内部只要是 Ruby 代码，有 GIL 锁，自带线程安全。

运行的是 Ruby 代码，多线程，只会轮替的使用一个核心。

Sinatra 挺好，保持很好的可读性

Roda 可读性不太好

服务器 Debian、Ubuntu

桌面 Linux Mint

Docker 镜像 Debian、Ubuntu、Alphine

比如你的实例 叫 instance

instance.class.ancestors.each {|klass| puts klass.instance_variables}

外国人比机器贵。价格不敏感。这样想想是不是就合理了。

COOL！

能否分享下，Ruby 的 GUI 应用如何解决打包、安装、跨平台分发的问题？

我有个理论就是寄生性语言都会死掉。

从 CoffeScript 开始，即使是今天热度很高的 TypeScript。他们都会因为 JavaScript 不断完善而被淘汰掉。

归根结底还是因为浏览器执行的就是 JavaScript，绑定 UI 的语言使用的是单线程的模型，不同于其他语言，思维方式不同。其他语言即使去封装，比如用 Ruby 语法写 JavaScript，最后结果就是：你不仅要关心 Ruby 还要关心 JavaScript 还要关心他们之间的差异和版本区别，痛苦翻倍。

如果你已经理解 JavaScript，还不如去写 JavaScript。最后就会发现这样的换写毫无意义。

除非 Ruby 被浏览器支持。但是不太可能。浏览器是比操作系统甚至还复杂的软件，他的更新换代周期很慢，牵扯很多，往往是厂商们博弈后的结果。最后，你没什么选择。市场现状也说明了这个问题。

做过一个类似的：

https://github.com/Mark24Code/vistual_call

举个例子，包在关心的部分，可以获得该处调用的图：

require "sinatra"
require_relative "vistual_call"

VistualCall.trace(theme: :lemon) do
  get "/" do
    "hello"
  end
end

+1 看 Ruby 资料最有趣的点在于，留下来的都是经得住时间考验的。

特性在试验中：

** Sets the storage hash for the fiber. This feature is experimental and may change in the future. **

不过依然可以给出例子

# Fiber#storage 例子
# https://devdocs.io/ruby~3.2/fiber#method-i-storage
puts "start..."

def work
  puts "work,running...."
  puts "work,set :tmp_value"

  # 可以携带数据，一直保持在这个 Fiber 中
  Fiber.current.storage = {
    payload: "some data"
  }
  puts "work,do some thing...."

  puts "work: tmp_value" ,Fiber.current.storage

  Fiber.yield 12
  puts "work,come back"
  puts "tmp_value:",Fiber.current.storage
end

puts "start...(before fiber)"
fiber = Fiber.new {
  work
}

fiber.resume
puts "back to main"
puts fiber.resume

puts "the end"

运行结果

start...
start...(before fiber)
work,running....
work,set :tmp_value
work,do some thing....
work: tmp_value
{:payload=>"some data"}  # 携带数据
back to main   # 切换会主干执行
work,come back  # 切换回 fiber
tmp_value:
{:payload=>"some data"} # 数据还在

the end

前端的方案有成本优势。 通过接口获得差异数据，前端动态生成 diff 组件。充分利用客户端算力。

后端的方案，压力全部自己扛。看钞能力。

Fiber#current: https://devdocs.io/ruby~3/fiber#method-c-current

我想看看楼主的技术分享。感觉也快用到了。真的是三端合一，这样的话，很有吸引力。

这里 PC、Mobile 完全不同，一套代码的意思是：

1.相同的代码，不同布局 2.写 2 份，根据设备情况各自分开展示

是哪种？

Thread.current，Fiber.current 往上面绑变量？

同意楼上。DHH 总是结合实践来说明问题。

前端娱乐圈总是嘴嗨更多。

如果观点不能跟随现实发生改变，其实就是一种固执己见，偏执人格障碍。

这个问题其实很简单，当网线足够宽，以前的那些省流的骚操作当然可以一并去掉了。就像现在，电话线上网那时候的“下载器”很少被人提起；直播、网上看剧成了主流。

其实是一样的。

基础设施好了，辅助设施就可以下架了。

https://solargraph.org/

https://shopify.github.io/ruby-lsp/